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REMARKS 

By this Amendment, claims 63 and 68 have been amended without any intention of 
narrowing the scope of any of the claims. Applicants have amended the currently pending 
claims in order to expedite prosecution and do not, by this amendment, intend to abandon 
subject matter of the claims as originally filed or later presented. Moreover, Applicants 
reserve the right to pursue such subject matter in a continuing application. Claims 1 and 57- 
75 are pending in this patent application. Reconsideration of the rejections in view of the 
remarks below is requested. 

Entry of the Amendment is proper under 37 C.F.R. §1 .1 16 as the amendments: (a) 
place the application in condition for allowance for the reasons discussed herein; (b) do not 
present any new issues that would require further consideration and/or search as the 
amendments merely amplify issues discussed throughout the prosecution; (c) do not present 
any additional claims without canceling a corresponding number of claims; (d) place the 
application in better form for appeal, should an appeal be necessary; and (e) were not made 
earlier because they are made in response to the points first presented in the final Office 
Action. Entry of the Amendment is thus respectfully requested along with withdrawal of the 
final Office Action. 

Claims 63-75 stand rejected under 35 U.S.C. §101 because the claimed invention is 
directed to non-statutory subject matter. The rejection is respectfully traversed. While 
expressly disagreeing with the rejection, Applicant has amended independent claims 63 and 
68 to recite a computer product embodied in a computer-readable media. Accordingly, 
Applicant requests that the rejection of claims 63-75 under 35 U.S.C. §101 be withdrawn and 
the claims allowed. 

Claims 1, 57-61 and 63-75 stand rejected under 35 U.S.C. §102(a) as being 
anticipated by United States patent no. 5,815,657 to Williams et al. ("Williams et al.")- The 
rejection is respectfully traversed. 

Williams et ah disclose an electronic monetary system that provides for transactions 
utilizing an electronic-monetary system that emulates a wallet or a purse that is customarily 
used for keeping money, credit cards and other forms of payment organized. A graphical 
representation of the payment instruments is presented on the display to enable a user to 
select a payment method of their choice. Once a payment instrument is selected, a summary 
of the goods for purchase are presented to the user and the user enters an electronic approval 
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for the transaction or cancels the transaction. Electronic approval results in the generation of 
an electronic transaction to complete the order. Williams et al., Abstract. 

Williams et al. further disclose that their monetary system comprises a Certificate 
Manager 304 that manages the automatic downloading of a consumer's certificate from a 
bank, validation of a consumer's and a merchant's certificates and automatic requisition of 
certificate renewal. The system further includes a Payment Manager 306 that coordinates and 
completes the payment request that is received from the merchant system. The payment 
request received contains the final GSO, Ship-To name, merchant certificate, merchant URL, 
coupons and the payment amount. The Payment Manager 306 then communicates with the 
payment related GUI component to interact with the consumer to authorize and complete the 
payment transaction. A user interfaces with the payment manager 430 via a user interface 400 
that responds to and sends a variety of transactions 410, 408, 406, 404 and 402. The 
transactions include obtaining the next record, payment record, receipt, acceptance of the 
payment instrument and GSO components. In turn, the payment manager 430 sends 
transactions 414 and receipts 420 to a wallet manager 422 and receives payment instruments, 
certificates and private keys from the wallet manager 422. The payment manager 430 also 
sends and receives transactions to a protocol manager 470 including a merchant's payment 
message 460, a consumer certificate and PK handle 450, a merchant URL 442, a payment 
440, a signed receipt 434 and a GSO, Selected Payment Protocol and Selected Payment 
Instrument 432. 

However, Applicant respectfully submits that the cited portions of Williams et al. fail 
to disclose, teach or suggest a method of managing reliance in an electronic transaction 
system as recited in claim 1. 

First, Applicant submits that the cited portions of Williams et al. fail to disclose, teach 
or suggest obtaining electronic signals representing a request for transactional assurance based 
on a transaction involving a subscriber as recited in claim 1 . The Examiner indicates that "the 
Payment Manager [of Williams et al.] receives the request for transactional assurance (i.e., 
authorization to pay or payment) from the merchant." However, the cited portions of Williams 
et al. merely disclose a Payment Manager that acts as a conduit to direct a request for payment 
(not a request for authorization to pay because after all it is the consumer that is paying, not 
the merchant or the Payment Manager) by a merchant to a consumer, from the merchant to the 
consumer and to handle the payment from the consumer to the merchant. There is simply no 
indication that the merchant makes any type of request to the Payment Manager for assurance 
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regarding a transaction with the consumer. A request for payment is not an assurance provided 
regarding the transaction; rather, it is simply a request for a constituent component of the 
transaction. Similarly, there is no indication that the consumer makes any type of request to 
the Payment Manager for assurance regarding a transaction with the merchant. The Payment 
Manager simply manages the mechanics of a request for payment by a merchant and the 
payment by the consumer, the consumer and merchant assuming the risks regarding the 
transaction with each other, and is simply not configured to accept a request for assurance 
regarding a transaction. 

Further, Applicant submits that the cited portions of Williams et al. fail to disclose, 
teach or suggest determining whether to provide the requested transactional assurance based 
on at least the subscriber assurance as recited in claim 1. While the cited portions of Williams 
et al. disclose that the Payment Manager receives and sends consumer and merchant 
certificates, they do not disclose, teach or suggest that the Payment Manager makes any 
decision based on any of those certificates, let alone whether to provide transactional 
assurance. 

The cited portions of Williams et al. also fail to disclose, teach or suggest issuing 
electronic signals representing transactional assurance to a relying party as recited in claim 1 . 
For example, there is no indication that the Payment Manager of Williams et al. is configured 
to issue any sort of assurance that the consumer's or merchant's certificate for the transaction 
is authentic or valid. Or, whether, for example, the Payment Manager is configured to issue 
any sort of assurance that the consumer or merchant exists and/or is in good standing. Or, 
more generally, whether the Payment Manager is configured to issue assurance regarding the 
transaction. The Payment Manager is merely an intermediary to facilitate the transaction 
between the merchant and consumer and does not facilitate issuance of any type of assurance 
regarding that transaction. Further, the Payment Window of Figure 34 of Williams et al. does 
not involve issuing signals representing transactional assurance to a relying party. The 
Payment Window is merely a vehicle for the consumer to issue payment to the merchant. It 
does not provide any assurance to the consumer that, for example, goods will be received, that 
the merchant is in good standing, etc. 

Claims 57-62 depend from claim 1 and are, therefore, patentable for at least the same 
reasons provided above related to claim 1 , and for the additional features recited therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams et al. fail to disclose, teach or suggest a computer program product, 
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embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
63, 

For example, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest creating a reliance request message specifying at least one aspect of 
the transaction upon which a relying party intends to rely as recited in claim 63. Further, 
Applicant submits that the cited portions of Williams et al. fail to disclose, teach or suggest 
causing electronic signals representing the reliance request message to be sent to a reliance 
server requesting a transactional assurance for the aspect of the transaction upon which the 
relying party intends to rely as recited in claim 63. 

Claims 64-67 depend from claim 63 and are, therefore, patentable for at least the same 
reasons provided above related to claim 63, and for the additional features recited therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams et al. fail to disclose, teach or suggest a computer program product, 
embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
68. 

For example, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest receiving electronic signals representing a reliance request 
message, the message specifying an aspect of a transaction with a subscriber upon which a 
relying party intends to rely and requesting assurance for the aspect of the transaction as 
recited in claim 68. Further, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest determining whether to provide transactional assurance based on 
the reliance request message and generating electronic signals representing an indication of 
whether transactional assurance is available as recited in claim 68. 

Claims 69-75 depend from claim 68 and are, therefore, patentable for at least the same 
reasons provided above related to claim 68, and for the additional features recited therein. 

Because the cited portions of Williams et al. fail to disclose, teach or suggest the 
claimed subject matter of claims 1, 57-61 and 63-75, Applicant respectfully requests that the 
rejection under 35 U.S.C. §102(a) of claims 1, 57-61 and 63-75 based on Williams et al. be 
withdrawn and the claims allowed. 

All objections and rejections having been addressed, it is respectfully submitted that 
the present application is in condition for allowance. If questions relating to patentability 
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remain, the examiner is invited to contact the undersigned to discuss them. 

Should any fees be due, please charge them to our deposit account no. 03-3975, under 
our order no. 061047/0268225. The Commissioner for Patents is also authorized to credit any 
over payments to the above-referenced deposit account. 



Respectfully submitted, 

PIfc1^URYMrrtTHR£>P SHAW POTMAN LLP 




Jean-Paul 
Reg. No 
Tel. No. 70 
Fax No. 703-7 



JGH 

P. O. Box 10500 
McLean, VA 22102 
(703) 770-7900 
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